A typical computer includes a memory that is, ultimately, accessible to any user of the computer. In the simplest computers, any unit of the memory (e.g., byte, word, double word, etc.) can be identified by its physical address, and a process controlled by any user can issue an instruction to read or write any location of the memory. More sophisticated computers support virtual addressing of the memory—i.e., identification of a memory unit by some value other than the unit's physical address. With virtual addressing, as is known in the art, a virtual address facility such as the computer's memory management unit (MMU) uses a set of translation maps to convert a virtual address into a physical address. When a system supports virtual addressing, any memory location can be made accessible by editing the address translation maps to assign a virtual address to the desired physical memory location.
Mechanisms exist that, in theory, separate memory into different portions such that not every memory location is accessible to every user or process. For example, some computers allow a range of memory to be designated for use only when the processor is operating in kernel mode. Some operating systems enforce a loose isolation among processes by assigning each process its own address space, where at least some portions of the various address spaces are non-overlapping. In a typical environment that supports paged virtual memory, the operating system typically will create page tables for each process such that each process has at least some pages that are not in the page tables for any other process. The same is true for environments whose virtual memory system is based on segmentation. (Page and segment tables are both examples of the more general terms “address translation data” or “address translation map.”)
A problem with all of the foregoing systems is that they make scant, if any, pretense at preventing their own defeat at the hands of a determined user. There is certainly a risk when a user edits an address translation map (e.g., the edit may introduce some inconsistency in the maps that causes the system to crash), but this danger will not discourage a skilled attacker who is bent on causing the system to behave in some way that is outside of the intentions of its designers. The page or segment tables may be specified as read-only; however, an attacker has a number of options to circumvent this type of protection, such as:                The attacker may be able to edit the read-only/read-write attributes (by running some rogue kernel mode component—such as a device driver—that makes the change in kernel mode), thereby making the address translation map writeable; or        The user can create an address translation map (e.g., a set of page tables or segment tables) from scratch, and then have a rogue kernel mode component load the base address of the new map into the register that specifies the entry point for the tables (e.g., by using a rogue device driver to load the base address of the new page directory into the CR3 register on an INTEL x86 processor).        In many systems, the user can employ a system debugger or kernel debugger to directly change address translations.        
As a general proposition, many prior art techniques that are designed to cordon off or isolate a section of memory can be easily circumvented by a local user. Thus, these techniques cannot be relied upon to enforce memory isolation in circumstances where the isolation is used to protect commercially-valuable information (e.g., the decryption key for a best-selling book or first-run movie, or the code that enforces electronic licenses to content or software, etc.), since it must be presumed either that the memory isolation technique was not designed to resist a willful attack, or that there will be sufficient incentive for a person to expend the effort necessary to circumvent the isolation technique.
Because the foregoing techniques are limited in their ability to truly enforce memory isolation, various other techniques have been developed. These techniques include:
Base-bound memory isolation. In this technique, the processor sets up a base-bound register area around a part of physical memory. The processor enforces the rule that trusted code can issue physical addresses to the protected area, but untrusted code cannot. While this technique is effective at isolating memory, it is very awkward, and that awkwardness would be visible to users. For example, since it is difficult to change the amount of trusted memory, the system may have plenty of untrusted memory, but be out of trusted memory (so some programs requiring trusted memory would be unable to run), or there may be long stalls (noticeable to the user) while the system tries to shift around untrusted areas so the trusted areas can be grown.
The proton core (also called thread differential address mapping). In a proton core, most operations execute in ring 1 (on an INTEL x86 processor), and every operation that would touch key I/O elements, or edit page maps, or do a variety of other things, is forced to fault to ring 0, where a small trusted supervisor would run and evaluate the legitimacy of the operation before it is performed. This technique is very inefficient. By one estimate, the overhead required to implement this scheme requires 75% of the available cycles on a machine.
Translation Lookahead Buffer (TLB) load filtering. In this approach, a list of trusted pages is kept. At TLB fill time, the physical page frame number is compared against the list. If the page being added to the TLB in the list (i.e., meaning that untrusted code is trying to load a mapping to a trusted page), the load fails. The problem with this approach is that its speed depends on how well the list of trusted pages is cached. If the list is cached poorly, this technique would add a memory fetch to the end of every TLB fill, which would have an unacceptable overhead cost.
In view of the foregoing, there is a need for a memory isolation technique that overcomes the drawbacks of the prior art.